Oh, some RegExp and Unicode, the two banes of my existence... 😅

Although this could be a nice addition, I'm not really fond of the idea of embedding a big chunk of Unicode data in a core parser library. (This is why only General_Category is supported currently to begin with.) Plus, even with this, there's a lot of further Unicode stuff that's still not covered AFAIK...

I think we need to take a step back here as I'm getting pretty convinced that this JS to .NET regexp conversion logic doesn't really belong in a parser library since it's about execution, not syntax. As a matter of fact, it's primarily for supporting Jint, so probably it'd belong there more (or, at least, in a separate package) if we consider responsibilities.

I feel even more strongly about this when I think about the Unicode sets mode, which is the only main blocker of ES2024+ support now.

Support for legacy Unicode mode (flag u) is quirky and limited but Unicode sets mode (flag v) is pretty much impossible to implement on top of the current .NET Regex engine. This is why I think it's not really worth putting additional significant effort in this approach, which will always be quirky, limited and fragile.

Instead, something like this looks like the way forward:

1. Porting the proper RegExp parser from acornjs. This would kill two birds with one stone: Acornima could validate and parse flag v regexps and could provide AST for a potential standards-compliant RegExp engine as well. (AI agents can probably help with this task a lot.)
2. Ripping the JS to .NET regexp conversion logic out of Acornima and placing it in a separate package. (In which I wouldn't mind including big amounts of Unicode data.)
3. Introducing an extension point (probably a callback) in Acornima that would allow the consumer to provide whatever JS to .NET regexp conversion logic they want to use. (This way the current conversion approach would still be available, but Acornima would only have the ability to validate and parse regexps into ASTs out of the box.)
4. Implementing a standards-compliant RegExp engine in Jint. (Of course, this is a huge task but in the era of AI agents nothing is impossible. 😉 Until it's done, Jint could, of course, continue using the current limited RegExp execution approach.)

At least, I don't really see another viable way of moving Acornima ahead and implementing Unicode sets in Jint.

I can't make promises but I plan to make progress with steps 1-3 in the coming months because this "flag v" thing has been bugging me for way too long now 😅

Just to be clear: I'm not rejecting this PR, it's just on hold until the refactor I outlined above is done.

Thanks for the feedback. I created this intentionally as draft as I was investigating how far I could go in fixing. So basically running Jint and Acornima sources together against failing tests.

Porting the proper RegExp parser from acornjs. This would kill two birds with one stone: Acornima could validate and parse flag v regexps and could provide AST for a potential standards-compliant RegExp engine as well. (AI agents can probably help with this task a lot.)

Yes, this kind of porting is exactly suited for AI agents, not a bad idea indeed.

Ripping the JS to .NET regexp conversion logic out of Acornima and placing it in a separate package. (In which I wouldn't mind including big amounts of Unicode data.)

If done, I would vote for something shipped as source package or source generator or similar, trying to keep dependency chain small.

Introducing an extension point (probably a callback) in Acornima that would allow the consumer to provide whatever JS to .NET regexp conversion logic they want to use. (This way the current conversion approach would still be available, but
Acornima would only have the ability to validate and parse regexps into ASTs out of the box.)

Sounds goo to me 👍🏻

Implementing a standards-compliant RegExp engine in Jint. (Of course, this is a huge task but in the era of AI agents nothing is impossible. 😉 Until it's done, Jint could, of course, continue using the current limited RegExp execution approach.)

There's a lot of samples of existing work, so shouldn't be impossible, performance is of course always a concern but maybe could utilize mixed-mode where usually done using .NET libraries and complex cases offload to another parser that might not be that fast (or support pre-compilation).

Custom regex engine in the works 😆 sebastienros/jint#2380

Wow, that was fast! 😮

Now all we need is a QuickJS bytecode-to-IL converter, and we can finally ditch that unholy hack called RegExp to Regex conversion. 😄

Or, even better, Jint could generate IL instead of some custom bytecode to begin with. 🤔

The interpreter might be somewhat trickier that way, however Claude might be able to cobble up an IL interpreter tailored to the problem based on some existing implementations such as the CoreCLR IL interpreter or https://github.com/Ourpalm/ILRuntime.

Yes, many possible venues to explore indeed. I'm on mobile now but I think at least v flag parsing was a problem. Need to check where the fix needs to go when back in front of keyboard...

As a matter of fact, the set of regexps that can be converted to .NET Regexs so they produce results compliant to the ES spec is pretty small: https://github.com/adams85/acornima/?tab=readme-ov-file#regular-expressions

Roughly, it's basic, case-sensitive, non-Unicode patterns. Beyond that, quirks start to appear.

I'm closing this in favor of #36 and #37 , there might still be some insight to extract to issues. But this PR's contents no longer serve a purpose.